In QuickOPC-UA, timeout values for certain QuickOPC tasks are accessible via properties on the EasyUAClient object. The explanation of the individual timeout values is provided in the Reference documentation.

The remainder of this chapter applies mainly to QuickOPC “Classic”.

The core QuickOPC methods (ReadItem, ReadItemValue, WriteItemValue, and their counterparts that work with multiple items at once) are all implemented as synchronous function calls with respect to the caller, i.e. they perform some operation and then return, passing the output to the caller at the moment of return. However, this does not mean that the component makes only synchronous calls to OPC servers while you are calling its methods. Instead, QuickOPC works in background (in separate threads of execution) and only uses the method calls you make as "hints" to perform proper data collection and modifications.

Internally, QuickOPC maintains connections to requested OPC servers and items, and it establishes the connections when you ask for reading or writing of certain OPC item. QuickOPC eventually disconnects from these servers and items if they are no longer in use or if their count goes beyond certain limits, using its own LRU-based algorithm (Least Recently Used).

When you call any of the core QuickOPC methods, the component first checks whether the requested item is already connected and available inside the component. If so, it uses it immediately (for reading, it may provide a cached value of it). At the same time, the request that you just made by calling the method is used for dynamic decisions on how often the item should be updated by the server etc.

If the item is not available, QuickOPC starts a process to obtain it. This process has many steps, as dictated by the OPC specifications, and it may take some significant time. The method call you just made does not wait indefinitely until the item becomes available. Instead, it uses certain timeout values, and if the item does not become available within these timeouts, the method call returns. The connection process is totally independent of the method that was called, meaning that no problem in the connection process (even an ill-behaved server, or a broken DCOM connection) can cause the calling method to wait longer than the timeouts dictate.

The timeout values are accessible via InstanceParameters.Timeouts property on the EasyDAClient object. The explanation of the individual timeout values is provided in the Reference documentation.

Note that if the nature of the situation allows the component to determine that the item will NOT be available, the method will return earlier (before the timeouts elapse) with the proper error indication. This means that not every connection problem causes the method to actually use the full value of the timeouts. For example, when the server refuses the item because the item has an incorrect name, this error is passed immediately to the caller.

It is important to understand that even if the method call times out because the connection process was not finished in time, the connection process itself is not cancelled and may continue internally. This means that next time the same item is requested, it may be instantly available if the connection process has finished. In other words, the timeouts described above affect the way the method call is executed with respect to the caller, but do not necessarily affect at all the way the connection is performed.

When you create an EasyDAClient object, the timeout values are set to reasonable defaults that work well with reporting or computation type of OPC applications. In these applications, you know that you MUST obtain certain value within a timeout, otherwise the application will not be doing what is intended to do: e.g. the report will not contain valid data, or the computations will not be performed. When the requested item is not instantly available (for example, the server is not started yet), the application can afford delays in processing (method calls made to EasyDAClient object may block the execution for certain time). For this kind of applications, you may leave the default timeout values, or you may adjust them based on the actual configuration and performance of your system.

There is also a different kind of applications, typically an HMI screen, which wants to periodically update the values of controls displayed to the user. The screen usually contains larger number of these controls that are refreshed in a cyclic way by the application. If possible, you should use subscription-based updated for these applications, and in such case the timeouts are of much lesser importance. But, in some application the subscriptions are not practical, and you resort to periodic reading (polling). The fact that SOME data is not instantly available should not be holding the update of others. It is perfectly OK to display an indication that the data is not available momentarily, and possibly display them in some future refresh cycle when they become available. For this kind of application, you may prefer to set all the above mentioned timeout properties to lower values. This assures that the refresh loop always goes quickly over all the controls on the screen, no matter whether the data is available for them immediately, or only in a postponed fashion.

To simplify this explanation, you can also say that if you need the OPC values for further *sequential* processing, reasonably long timeouts are needed (and the defaults should serve well in most situations). If you are refreshing the data on a *cyclic* basis by polling, you will probably need to set the timeouts to lower values.